High Efficiency Video Coding (HEVC) is a new coding standard that has been developed in recent years. In the High Efficiency Video Coding (HEVC) system, the fixed-size macroblock of H.264/AVC is replaced by a flexible block, named coding unit (CU). Pixels in the CU share the same coding parameters to improve coding efficiency. A CU may begin with a largest CU (LCU), which is also referred as coded tree unit (CTU) in HEVC. In addition to the concept of coding unit, the concept of prediction unit (PU) is also introduced in HEVC. Once the splitting of CU hierarchical tree is done, each leaf CU is further split into one or more prediction units (PUs) according to prediction type and PU partition. Several coding tools for screen content coding have been developed. These tools related to the present invention are briefly reviewed as follow.
Three-dimensional (3D) television has been a technology trend in recent years that is targeted to bring viewers sensational viewing experience. Multi-view video is a technique to capture and render 3D video. The multi-view video is typically created by capturing a scene using multiple cameras simultaneously, where the multiple cameras are properly located so that each camera captures the scene from one viewpoint. The multi-view video with a large number of video sequences associated with the views represents a massive amount data. Accordingly, the multi-view video will require a large storage space to store and/or a high bandwidth to transmit. Therefore, multi-view video coding techniques have been developed in the field to reduce the required storage space and the transmission bandwidth. In three-dimensional and multi-view coding systems, the texture data as well as depth data are coded.
Various coding tools have been developed to enhance the depth picture coding efficiency. Among these tools, the two Depth Modeling Modes (DMM1 and DMM4) have been adopted into three-dimensional (3D) video coding standard such as 3D video coding based on High Efficiency Video Coding (3D-HEVC) to improve the Intra prediction efficiency of depth pictures. DMM1 and DMM4 are based on wedgelet and contour partitioning respectively. For a wedgelet partition, the two regions are separated by a straight line, as illustrated in FIG. 1A through FIG. 1C, where the two regions are labelled with P1 and P2. The separation line is determined by a start point S and an end point E, both located on different edges of the block as shown in FIG. 1A, which illustrates a case for the continuous signal and the separation line can be described by an equation for a straight line. FIG. 1B illustrates a case for the discrete sample space, where the block consists of an array of samples with a block size uB×vB and the start and end points correspond to edge samples. Though the separation line can be described by a line equation for the discrete space as well, each boundary sample between regions P1 and P2 may not be entirely on one side of the boundary line. Since each entire sample at the boundary has to be assigned to one of the two regions, a boundary sample may appear to be on both sides of the boundary line as shown in FIG. 1B. In order to use the wedgelet block partitions in the coding process, the partition information is stored in the form of partition patterns (also referred as wedgelet patterns). The partition pattern consists of an array of uB×vB binary data to indicate whether the sample belongs to region P1 or P2. The regions P1 and P2 are represented by black and white samples respectively in FIG. 1C. The term “wedgelet” may also be referred as “wedge” in this disclosure.
Unlike the wedgelets, the separation line between the two regions of a contour partition of a block cannot be easily described by a geometrical function. FIG. 2A thought FIG. 2C illustrate examples of contour partition of a block, where the block consists of two arbitrary shaped regions P1 and P2, and P2 consist of multiple parts. FIG. 2A illustrates an example of arbitrary shaped contour partition for the continuous space. FIG. 2B illustrates an example of arbitrary shaped contour partition for the discrete space. Other than separation by a line or an arbitrary shaped contour, wedgelet and contour partitions are very similar. In order to use the contour partitions in the coding process, the partition information is also stored in the form of partition patterns. FIG. 2C illustrates an example of binary pattern corresponding to the contour partition in FIG. 2B. The binary pattern has to be derived individually for each block from the signal of a reference block. Due to the lack of a functional description of the arbitrary shaped contour line between regions, no pattern lookup lists can be used. Consequently no search of the best matching partition can be used for contour partitions.
While DMM1 has the advantage of significant BD-Rate savings, the number of wedgelet patterns for DMM1 requires a large table in both the encoder and the decoder to store the candidate patterns for Intra prediction. The BD-Rate is a well-known performance measure used in video coding system. Table 1 lists the size of each wedgelet pattern table for each Intra PU size in the 3D-HEVC Draft Text 5 (Tech et al., 3D-HEVC Draft Text 5, Joint Collaborative Team on 3D Video Coding Extensions of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 9th Meeting: Sapporo, J P, 3-9 Jul. 2014, Document: JCT3V-I1001).
TABLE 1NumberNumber ofAc-of bits for onecumu-wedgeletwedgeletTotallatedPU sizepatternspatternbitsbitsBits ratio [%]4 × 4  8616 1,376 1,376 0.35% (1376/396000)8 × 8  76664 46,024 50,40011.62% (46024/396000)>=16 × 161,350256 345,600396,00087.27%(345600/396000)
The wedgelet patterns of DMM1 can be classified into six direction categories (also referred as wedgelet direction categories), as shown in FIG. 3A through FIG. 3F. The six direction categories include four corner directions, vertical direction and horizontal direction. For corner directions (also referred as adjacent-edge partitions), the edge line starting positions and ending positions are on two adjacent edges joined by the corner sample. For example, the starting positions are in the edge corresponding to the row of samples at the bottom in FIG. 3A. The ending positions are located in the edge corresponding to the column of samples at the left in FIG. 3A. For the opposite-edge directions (i.e., vertical and horizontal in FIG. 3C and FIG. 3F respectively), the two edges for the starting and ending positions are on the opposite sides. The opposite-edge directions may also referred as opposite-edge partitions. As shown above, the table size for DMM1 is quite large. Therefore, it is desirable to develop a method to reduce the wedgelet pattern table size. However, reducing the wedgelet pattern table size may cause impact on the coding efficiency. Furthermore, it is desirable that the reduced wedgelet pattern table size will have very small or no impact on the coding efficiency.
In the current 3D-HEVC described in JCT3V-I1001, the table index in DMM1 is binarized as a fixed-length code as described in the syntax table (Table 2) and in the binarization table (Table 3).
TABLE 2Descriptorif( DepthIntraMode[x0][y0] == INTRA_DEP_DMM_WFULL )    wedge_full_tab_idx[x0 ][y0]ae(v)
TABLE 3wedge_full_tab_idxFLcMax = wedgeFullTabIdxBits[log2PbSize]
where cMax represents the code bit length of the fixed length code and wedge_full_tab_idx[x0][y0] specifies the index of the wedgelet pattern in the corresponding pattern list when DepthIntraMode[x0][y0] is equal to INTRA_DEP_DMM_WFUL.
The wedgelet pattern can be determined according to: wedgePattern=WedgePatternTable[Log 2(nTbS)][wedge_full_tab_idx[xTb][yTb]], where WedgePatternTable[log2BlkSize] represents the list used to store binary partition patterns for a block with a block size 2log2BlkSize×2log2BlkSize.
NumWedgePattern[log2BlkSize] specifies the number of binary partition patterns in list WedgePatternTable[log2BlkSize].
The wedgelet pattern table WedgePatternTable[log2BlkSize] is constructed according to a pre-defined algorithm and the number of wedgelet patterns NumWedgePattern[log2BlkSize] is also determined by this algorithm. Table 4 illustrates NumWedgePattern[log2BlkSize] for different log2BlkSize.
TABLE 4NumWedgePatternlog2PbSize23456Value8676613501350—
Table 5 illustrates wedgeFullTabIdxBits[log2Pb Size] for different log2BlkSize.
TABLE 5Initialization variablewedgeFullTabIdxBitslog2PbSize23456Value710111113
The terms Log2(nTbS), log2PbSize and log2BlkSize mentioned above have the same meaning.
A problem occurs for the following case:                NumWedgePattern[log2BlkSize]<2wedgeFullTabIdxBits[log2BlkSize].        
When the above case occurs, the decoder may encounter a bitstream that signals a wedge_full_tab_idx larger than or equal to NumWedgePattern[log2BlkSize]. Since WedgePatternTable[log2BlkSize] is constructed with only NumWedgePattern [log2BlkSize] entries, the access of WedgePatternTable[log2BlkSize] [wedge_full_tab_idx] with wedge_full_tab_idx>=NumWedgePattern[log2BlkSize] undefined will cause an unpredictable results or an error. Accordingly, it is desirable to develop a method for wedgelet tables to overcome the issue.